Games of Daze/Infomagic - Games of Daze (Summer 1995) (Disc 1 of 2).iso/x2ftp/msdos/fg/qf2/qf.doc

Text File | 1995-04-10 | 12KB | 298 lines

                     Quickfire: The Reincarnation
                           by Diana Gruber

This is the second release of Quickfire. The original beta version
of Quickfire was released in 1993 as a demo of a graphics library
and a sound toolkit. The file was called "QF01B.ZIP", that's "B for
Beta", meaning the program was not finished. I always intended to
finish the program and turn it into a game, but I never got around
to it. So poor Quickfire circulated in a state of perpetual beta
for the past two years.

Many people have asked me to release the source code for Quickfire.
I have not done up until this point for several reasons. First, there
was the problem with the sound and music libraries. Originally,
Quickfire was released with beautiful music by Rob Wallace, and John
Ratcliff generously provided the drivers to play the music. The source
code to rebuild Quickfire would require linking with John Ratcliff's
code. Since I didn't have his permission to distribute his libraries
with Quickfire (and since it would have added considerable size to
the distribution if I did) I delayed the release.

Also, I kept thinking I was going to turn Quickfire into a "real"
game. It is such a pretty little shooter, it deserves to move beyond
the demo phase. I don't know if that will ever happen, but at this
point in my busy life, I think if anybody is going to create a real
game with Quickfire, it will be someone other than me. (Feel free
to try, just please talk to me before you release it. The code is
still copyrighted, but I'm real open to working with other developers
on this. Let's talk.)

So why am I releasing the Quickfire source code now?

Mainly for intellectual curiosity. There has been a debate for some
time on the best way to do 8-directional fast scrolling in an arcade
game. Is it better to build screens in video memory and use a mode X
page-flipping technique, or does it work better if you build the
screens in RAM and blast them to the screen in mode 13h? I decided to
try it both ways and see. The enclosed code accomplishes the
scrolling using two different methods. Results are listed below.

Installing and Running Quickfire
--------------------------------

Just copy it into a subdirectory. This is not a very complicated
program. The music and sound has been stripped out to simplify it
even more. The files you need to run the program are as follows:

 QF13H.EXE -- mode 13h version of Quickfire
 QFX.EXE   -- mode X version of Quickfire
 QF.PCX    -- background tiles
 QF1.PCX   -- title screen
 QF.BMP    -- sprite bitmaps
 QF.LEV    -- level map data

Run either one of the EXE files to see Quickfire. On exit, the frame
rate will be displayed on the screen. Quickfire will run in self-play
demo mode unless you press a key. The following keys will control
Quickfire:

 UP, DOWN, LEFT, RIGHT -- move around
 CTRL -- shoot
 ESC  -- QUIT

Pressing two keys together, for example UP and LEFT, will cause
Quickfire to "roll".

In general, the program runs too fast to be playable.

Programming Considerations
--------------------------

The source code exists in the following three files:

 QF.C      -- animation functions and function main
 LOADGAME.C-- initialization, termination, etc.
 DEFS.H    -- global declarations and definitions

Quickfire requires Fastgraph 4.0 to link. If you have Fastgraph/Light
4.02, you can relink Quickfire in real mode only, which means you can
only use the mode X method. If you have an earlier version of
Fastgraph or Fastgraph/Light, you can re-link in real mode, but you
need to remove the call to fg_initpm().

I compiled the code in Watcom 10.0, using the DOS4GW DOS extender
from Rational Systems (now Tenberry). It should work with other
compilers and DOS extenders as well. I linked with Fastgraph 4.02.

For those who want to compare results with out recompiling and
relinking, I included EXE files for the program both ways. QF13H.EXE
shows the program in mode 13h and QFX.EXE shows the program in
mode X. If you rebuild the program, I suggest you call it simply
qf.exe. I have included a batch file

 WCR.BAT

To build the program with Watcom C. I also included a file called

 WORK

Which works with the Microsoft Make utility to build files with
the Microsoft C compiler (real mode only). If you want to compile
with Borland, you will need to make a project file. You can do
that yourself, just add the two source code files and the Fastgraph
library.

Two Strategies in One Program
-----------------------------

Experimenting with various video modes and blitting strategies is
very easy with Fastgraph. There is no need to suffer the headache
of rewriting the low-level code from scratch, knowing that half of
what you write is going to be thrown out before the final product
is released. Fastgraph allows you to prototype a game several ways
and choose the preferred method.

This is especially important in a case like this where there is no
"right" or "wrong" way to write the program. While one method may
sound more appealing at the beginning, you can easily change your
strategy half way through without throwing out all your code. To
demonstrate this, I incorporated both methods in a single source code
set.

A preprocessor directive is used to distinguish between the mode X
code and the mode 13h code. It is defined in the file DEFS.H, as
follows:

//#define ModeX

Uncomment this line to make the program run in mode X. Otherwise, it
will default to mode 13h. There are just a few places where the
preprocessor directive is used. For example:

#ifdef ModeX
   fg_transfer(0,351,vpo,vpb,0,hpb,0,0);
#else
   fg_vbcopy(0,351,vpo,vpb,0,hpb,workvb,workvb);
#endif

This means the mode X method requires a "transfer" from video memory
to video momory, while the mode 13h method requires a virtual buffer
copy.  The coordinates are the same, only the source and destination
change.

Another interesting place where the preprocessor directive is applied
is in the function swap(). Originally, this function was supposed to
simulate page flipping by moving the origin of the visual page. In
the mode 13h method, it does the fast 32-bit blit from RAM to video
memory as follows:

#ifdef ModeX
   fg_pan(screen_orgx,screen_orgy+vpo);
#else
   x1 = screen_orgx;
   x2 = x1+319;
   y1 = screen_orgy+vpo;
   y2 = y1+199;
   fg_vbpaste(x1,x2,y1,y2,0,199);
#endif

There are a few other places where the code differs between the two
methods, especially in the initialization functions in the file
LOADGAME.C.

Results
-------

Results of the experiment are mixed. I still haven't decided which
strategy is the best. If I were going to turn this into a game, I
would choose the strategy based on other considerations, such as
what sound library I planned to use. Not all sound libraries support
protected mode.

Here are the results I noticed:

Speed:

The mode 13h version is faster on my system. The mode X version
would be faster, except that you have to wait for the vertical
retrace. These results might be different on a slower computer,
where the animation occurs slower than the retrace rate.

Flicker:

The mode 13h version barely flickers, even when there are
no checks for the vertical retrace. The mode X version only
flickers when the retrace is turned off. Note that the background
artwork hides the flickering. That is, the sky and clouds lend
themselves to a certain amount of flickering without loss of
aesthetic quality. On a more clearly defined tile background (walls
and platforms) flickering may be more pronounced.

Jumpiness:

In the mode X version, there is a barely-noticeable jump during the
scroll when there are column and row rebuilds. On some systems this
is worse than on others. The mode 13h version is smooth as silk.
Note that the jumpiness is especially noticeable in this particular
demo because it attempts to do continuous scrolling. Most games don't
scroll continuously. They focus on a part of a level, where a sprite
will run around and jump and shoot, and the scrolling is sporatic. In
a game like that, the jumpiness would be hidden in the other motion.

Compatibility:

The mode 13h method uses 32-bit protected mode. That means it
requires a 386 or better system with at least 2 megabytes of RAM.
The EXE was built with Watcom C/C++ version 10, so it requires the
Rational Systems DOS/4GW DOS extender run-time module (DOS4GW.EXE).
The mode X version can be recompiled in real mode and run in under
512k.

Sprites:

The more sprites on the screen, and the larger they are, the more
speed degradation you will see in the mode X version (because more
tiles will need to be replaced each frame). In the mode 13h version,
the size and number of sprites is almost irrelevant (because they are
simply data moves in system RAM, which is very fast). I would expect
a major speed degradation.

Speeding up the Virtual Buffers
-------------------------------

I organized the graphics in RAM exactly the same way they were
organized in video memory. That is, I allocated a virtual buffer
exactly the same size as the resized video memory, and I built each
frame by replacing dirty tiles. The data moves are much faster in RAM
than in video memory, but there is still overhead involved in
building a buffer from tiles. A quicker way to build screens would be
to build the entire level at load time in a huge RAM array, and then
just locate the part of the level you need for a screen and blit
that. I believe this method would also simplify the code
significantly. It would, however, require at least 4 megabytes of
system RAM to work -- probably not unreasonable for modern games.

I haven't written the code to try that yet. I will probably start
working on that soon.

Speeding up the Mode X method
-----------------------------

The greatest overhead in building a screen from tiles comes from
calculating the video memory locations for the source and destination
of the tiles. This can be optimized by pre-calculating the tile
locations, as done in the function fg_copytile(), found in the file
COPYTILE.ASM. The assembly language source code is included with
this distribution. To insert it into the Quickfire source code,
link with COPYTILE.OBJ and replace the function put_tile() with
this macro:

#define put_tile(i,j) copytile((int)backtile[i+tile_orgx][j+tile_orgy],i,j,hidden);

Don't use the copytile function in protected mode, it was written
to work in real mode in the medium or large model.

Again, you will most likely only see a significant improvement on
systems where the animation is slower than the vertical retrace rate.
On a 386 or lower the speed boost will be more significant than on a
486 or higher. Try it and see.

Conclusions
-----------

I believe this experiment proves conclusively that both methods work
perfectly well for tile-based scrolling. The method to choose for a
game depend on other factors, such as the type of game, the artwork,
and the sound library.

Acknowledgements
----------------

I would like to thank Les Pardew of Cygnus Multimedia for contributing
the artwork. I'd also like to thank everybody helped with this
project, including (but not limited to) Ted Gruber, Mark Betz, Rob
Wallace, John Ratcliff, and Karen Crowther.

For more information about Fastgraph contact:
--------------------------------------------

Ted Gruber Software
P.O. Box 13408
Las Vegas, NV 89112
[phone] (voice)
[phone] (fax)
[phone] (bbs)

Internet:
ftp.accessnv.com \fg for files
72000,[e-mail] for email
[e-mail] for flames <g>

Helpful forums:
GO GAMEDEV on CompuServe
rec.games.programmer in the Internet

To get the free Fastgraph/Light evaluation kit, just ask!